In the first, second and early releases of third generation of mobile communications networks (i.e., global system for mobile communications (GSM), GPRS, code division multiple access (CDMA) 1×, UMTS, the GSM/GPRS/CDMA base station controller (BSC) and UMTS radio (radio network controller (RNC)) were restricted to connect to a single core network (CN) node. This strict hierarchy resulted not only in inefficiency of CN node utilization but service providers were forced to add more CN nodes in areas with more BSCs/RNCs even if the adjoining area CN node had excess capacity in terms of the number of BSCs/RNCs it could connect to.
Third Generation Partnership Project (3GPP) TS 23.236 defines technical requirements for Iu-flex, a mechanism whereby radio access nodes, such as RNCs, can select any core network node, such as a serving GPRS support node (SGSN) or mobile switching center (MSC) from a pool of CN nodes that serves a specific geographic area. The group of CN nodes that serve a pool area is referred to as the MSC pool or the SGSN pool. Allowing access nodes to select from multiple CN nodes within a pool area increases the efficiency of utilization of CN node resources. A TS 23.236A pool-area is an area within which a mobile station (MS) may roam without a need to change the serving CN node. A pool area is served by one or more CN nodes in parallel. The complete service area of a radio access network (RAN) node belongs to the same one or more pool-area(s).
The Network Resource Identifier (NRI) 4C01 identifies uniquely an individual CN node out of all CN nodes, which serve in parallel a pool-area. An NRI identifies uniquely a CN node within a RAN node. The NRI is carried as part of the temporary identity packet temporary mobile subscriber identity (P-TMSI), which is assigned by the serving CN node to the mobile subscriber (MS). Each CN node which supports the “Intra Domain Connection of RAN Nodes to Multiple CN Nodes” is configured with its specific one or more NRI(s). The P-TMSI allocation mechanism in the CN node generates P-TMSIs which contain a configured NRI in the relevant bit positions. The NRI has a flexible length between 0 and 10 bits (wherein the 0 bits means the NRI is not used and the feature is not applied). The RAN uses specific bits in the P-TMSI or international mobile subscriber identities (IMSIs) to determine the NRI which is relevant to identify the CN node. The functionality to select the core network node is called NAS Node Selection Function (NNSF). NAS stands for Non-Access Stratum since the interaction with core network is not at the radio access level.
Clearly the NAS Node Selection Function is a good candidate for balancing the load between the available CN nodes. However, being located in the RAN node, the NNSF process may not have visibility in respective loading of the CN nodes. Since the load-balancing process is left as implementation specific it hard to expect an efficient balancing when RAN includes multiple vendors or when the deployment includes small and large cells.
The concept of selecting a CN node has been extended to include machine type communication (M2M). Many M2M devices have low priority in accessing the network and NNSF can be used to select a CN node that is specifically designated/designed to handle Machine Type Communications.
It is clear from the foregoing that locating NNSF in the RAN node has significant implications for an RNC or evolved/enhanced node B (eNB), since it needs to be upgraded/augmented with NNSF, it has to be configured with NRI to CN node mapping and with a load balancing process that can collect the right load information. FIG. 1 illustrates an Iu-flex and S1-flex implementation.
There is a related concept of the network sharing where the RAN node could select a CN node from different operators. 3GPP TS 23.251 defines network sharing and multi-operator core networks (MOCN) operation which creates a scenario where a single RNC needs to connect to more than one CN node, in this scenario the CN nodes may belong to different service providers. FIG. 2 illustrates an example of MOCN operation. The mechanisms of MOCN have been extended to LTE Evolved Packet System. For the MOCN functionality to work the CN is identified by the public land mobile network identity
(PLMN-id) (mobile country code (MCC)+mobile network code (MNC)). The MCC is the mobile country code and the MNC is the mobile network code that identifies an operator within the country. The IMSI has three parts MCC, MNC and a mobile subscriber identity (MSIN)). The MSIN part in conjunction with MCC+MNC uniquely identifies a subscriber anywhere in the world. Thus in MOCN operation, the RNC/eNB looks at the MNC part or the IMSI and selects the CN nodes for that operator. Once the subscriber is mapped in corresponding operators CN node, the RNC/eNB nodes are required to maintain this association so that subsequent signaling goes to the right CN node. The associations between the RNC/eNB and CN nodes are Iu and S1 both of which involve several layers of protocols. As described in the prior art (e.g., Ericsson Patent application WO 2011/115543), the selection criteria can be extended to higher bits of MSIN and that application also indicates how the MOCN mechanism can be extended to accommodate Machine Type Communication within a single operator.
Just as in the case of Iu-Flex/S1-Flex, the location of intelligence in a Radio Access Node regarding the right CN node has it challenges. Not only do all RAN nodes need to be configured with multiple connections and configurations, they have to maintain association for each active user equipment (UE) with the selected CN node since the selection criteria may not be present in the subsequent signaling. Moreover, for many legacy UEs, RAN nodes may never have enough information to select the right CN node. FIG. 3 illustrates this point where a legacy UE attempts to connect and is redirected sequentially by the first CN node to the next and so on until the right node is found.
3GPP TR 23.823 describes an architecture where the NAS node selection function is located above the RNC. However, like TS 23.236, TS 23.823 indicates that the load-balancing algorithm is implementation specific. In addition, TR 23.823 indicates that the NNSF can be located in a stand-alone intermediary node or co-located with another node, but does not specify the node type with which the NNSF can be co-located.
While Iu-flex “pooling” and MOCN features are being used, their deployment has been limited due to these reasons. These issues become an order of magnitude bigger in LTE where there are many more eNBs. Just to understand the scale, in 3G networks, a couple of thousand nodeBs connect to an RNC and tens of RNCs share an Iu-flex pool. In LTE there are tens of thousands of eNBs connecting to a few mobility management entities (MMEs) in a pool.
Clearly, configuring such a large number of nodes with an MNC or NNSF process creates a challenge.